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(54) Method and computer program p«)duct for reducing inter-buffer data transfers between 
separate processing components 

(57) A method and computer program product for 
overcoming the inefficiencies associated with inter- 
buffer data transfers between separate processing com- 
ponents such as kernel mode drivers that are chained 
together. Provided is a standard mechanism for allocat- 
ing and managing data buffers needed for processing 
data in a system, wherein multiple drivers are chained 
together using a standardized connection method in the 

connection pin instances. Drivers having different buffer 
requirements and capabilities may be queried and 
matched for easy data transition between the chained 
drivers requiring the least number of buffers and, hence 

the least expensive yet most efficient inter-buffer data 
transfer. Examples of buffer requirements include previ- 
ous frame storage for adaptive processing, byte align- 
ment, frame size, outstanding frames allowed, etc. The 
buffer requirements of an input connection pin instance 
may be queried by an application initializing the chained 
drivers. When a buffer is needed, a buffer allocator will 
be associated with the input pin instance, othenwise a 
driver will process the data in the previous existing 
buffer. 
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software frameworks, conventior^s. etc. to ^'"1^^^^ ^^^^^^^^^^^^ products for managing buffers 

More specifically, the present .nvention .s ^'^^^.l ° Trfd^vers^s^^^^^^ minimum amount of inter-buffer data trans- 

nhenmuitipiecomponentsprocessastreamoram^^^^^^^^^ 

a frame, into a buffer, process the Vl'^'nTn ndero o^^^^^^^^ the sheer volume of data transfers 

r^=nt;a:;p=^^^^^^^^^ 

may occur With ^ 

acute with the media data found in multimedia f P''^^^"J^IJ^ ce a ve°^^^^^ "stream" of continuous data for 
erated that is in many instances tied to a t'-^J;^";^^? ..^"^^^^^^^^^^ line, digitizing hardware, etc. or 

""^ a multimedia environment. When processing a stream^^^^^^^^ 
data transfers between different bufferscreatesaa^^^^^^^^^^^^ 

performance of a hardware/software system. A P^°^i'^^^ on general purpose computer systems 

handle in terms of multimedia capab.hties_The — .fe^^^^J^^^^^^^ Listing demands on the processor, 
such as a processor running Windows NT- "^'J^Jff^^^^ J^^/"^^^ appLtions that would otherwise 

Reducing latency problems opens -^f ^^J,"^^^^^ e^Siciency and other means, a general 

be unavailable. If latency is s^ff'^'^-; ^ ^^"^^^J '"^raSS^^ P^^'^^'^' 
purpose computer system will be ^.^^^^^^^^^ -"^P^"^"^ 

Another problem associated with multiple buffers c™ona g ;,ij.ations. In other words, if each process- 
of system resources that may be used and therefore unava a^^^^ such ^s s^s em memory, system resources become 
, ing component has its own buffer taken from s^^^^^^^^ 

more scarce thereby causing inefficiencies the resource allocation problem.and 

another application. interconnect software drivers to that processing may occur in 

in a multimedia environment, it is advantageous t° 'f '^^o""^^^^^ . little security protection to allow 
softwaredriversthat run in aoperating ^V^^^.^^!^;,:^',^ ™ Many applications are benefrted by 

access to actual hardware that the drivers, in "'^'^J^^^l'l^'^^^ throughout, in Windows NT terminology 
,0 runninginthislooserandmoreperformance-onent^m^^^^ 

as "kernel mode". Other robust operating ^^^^^J^' "/^^^^^^^ mode drivers, used throughout this 

One prime example of a program ^^.^'^'1'"^^^°''^^^^ 

slstenl stream nature of multimeda passing/etching back and forth 

=° rererurnS:»s^car::cr::t:T^^^^^^^^^ 

n°in,.e. processing «^ wii, -*„^-3t::~Zr:rroS^^^^^^^^ 
tions between user mode and kernel mode 3g vansitions between user mode kernel 

" :rrra"="^f— ^ 

"'CatiS^Ta^f^nrsmtrt^^^^ 
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plurality of separate and distinct processing components. 

The invention also seeks to reduce latency effects .n -""^'"^^^ ^^^^^ applications having multiple processing 

ular component. available buffer allocation mechanisms as part of inter- 

,.:j::e:r cC - -~ ^" ~ 

^^'°^SS=^^esamethoda^^^^^ 

between separate processing components .s provided. A process^g ^°"^P°^^^^^^^ ^^^^ ^ 3,pport as well as 
have certain buffering requirements such as byte ^""^^^ J^^f J^^^^^^^^^^^^ buffer may 

. buffer creation and management capabilities in itself) being given to another 

then be created with some reference (e.g., reference to b^e^ J^^^^ 

. n processing component win, ^^^.^^^^^^ ^SSi^=SL;Sr S 
processing component in the chain. Since different ^^^"^ "^f "P^^^^^ on the particular processing 

One embodiment of the present '"mention occurs as part of cmnedi^^^^^^^^ ^^^^^^ 
to connection pin facKries. such capabil,l,es.n,dude«hatta^^^^^ 

rrs^r^rorrnrn^rrrc^^^ 

that the optimal connection "«»^f ™' , ^ determine whether a Ixifler allocator need be cre- 

. .«,?^at;rx7s:">^^^^^^^^ 

""Se1SXa;Trenlnterconnects.he*i.e.^^^^^^^ 

pin factories found on thelllters^ The agent will sped, ^^'^^X^M^'^S'^'^X'. th« Ihi-d 1^ 



will leave the data in the existing data after processing. 

In order to create a compliant driver, a driver developer will support certain standard facilities to allow a user mode 
agent to query capabilities and make interconnections between drivers. In one embodiment built on the Windows NT 
operating system, this is achieved by use of "sets" (;.e., property, method, and event sets) that implement the desired 
functionality. 

A set is logically defined as having a QUID (globally unique identifier) to identify the set as a whole and a RUID (rel- 
atively unique identifier, e.g.. relative within the set itself) for each element of functionality within the set. Each set is 
associated with only one or two lOCTLs (10 Controls), and an lOCTL combined with a set specification controls all inter- 
action with the driver. 

As currently embodied, three types of sets are utilized, namely, property sets, method sets, and event sets. Prop- 
erty sets are used for managing values or settings within the driver, such as sound volume, transfer rate, etc, and use 
a single lOCTL with a flag indicating whether the call is getting a property value and or setting a property value. Method 
sets are used for managing the operations that a driver may perform, such as allocating memory, flushing buffers, etc, 
and uses a single lOCTLto call the specified method. Event sets are used for managing events associated with driver 
processing, such as device change notification, data starvation notification, etc, and uses two lOCTLs, one for enabling 
a specified event and one for disabling a specified event. 

To use a set. an I/O control operation is initiated using the specified lOCTL and reference to a data structure having 
the set QUID, RUID, and other necessary data. For example, setting a volume property on a sound card driver would 
entail an I/O control operation using a set property lOCTL, specifying the appropriate QUID for the property set having 
the volume setting, indicating the specific RUID within that set indicates the volume property, and containing the new 
volume setting value. 

To query the sets supported, a null GUID is used along with a query flag on a specified lOCTL for a particular set 
type (e.g., property set lOCTL, method lOCTL, or event enable lOCTL) and a list of set GUIDs supported will be 
returned. To query supported properties, methods, or events within a given set, the set GUID, set type lOCTL, and a 
query flag are used with the operation returning a list of supported RUIDs. 

By using the generic set mechanism, a minimum of functionality may be implemented to support a compliant driver 
but still allow unlimited extensibility. A set may be defined in a written specification that can be independently coded by 
a multitude of different driver developers to create a system of interoperable and interconnectable drivers as long as 
particular sets are implemented. Furthermore, the specification can define mandatory properties, methods, and events 
that must be supported as well as optional properties, methods, and events that can be implemented depending on the 
driver functions and advanced capabilities. In addition to the basic minimum commonality required, driver developers 
may incorporate additional functionality by defining their own sets and assigning them a GUID. By being able to enu- 
merate supported functionality (i.e.. make queries for supported GUIDs and RUIDs), a caller, such as a third party con- 
trolling agent, can adjust expectations or make appropriate compensation d^ending on the capabilities of the 
underlying filters. 

In order to create a buffer allocator instance, a create I/O operation is again used specifying the particular connec- 
tion pin instance by its handle as parent will return another handle representing the buffer allocator. This buffer allocator 
handle is then placed in a property found on a source connection pin instance so that the filter knows to transfer data 
to the new buffer managed by the indicated buffer allocator utilizing appropriate stream I/O operations. 

As used herein, the term "user mode" refers to a level of operation in an operating system where most user written 
programs run. The user mode level of operation is typically the most secure level and has a significant amount of over- 
head to prevent one application program or process from interfering with another application program or process. Fur- 
thermore, access to system resources is highly controlled through specific interfaces and run priority is generally one 
of the lowest, if not the lowest. 

As used herein, the term "kernel mode" refers to a level of operation in an operating system having significantly less 
restrictions than the user mode level of operation. Examples of kernel mode programs or processes would include soft- 
ware drivers for controlling hardware components. Typically, kernel mode programs are performance sensitive, and 
therefore, have less operational overhead than user mode programs. Furthermore, access to hardware and many sys- 
tem resources is unrestricted or much less restricted than for user mode programs. In many instances, program code 
running in kernel mode relies on programmer discipline and conformity to convention in order to establish good system 
behaviour (e.g.. not disrupting another program's address space, etc.). Another term used for kernel mode is "trusted" 

As used herein the term "driver" refers to software driver programs typically running in kernel mode. The term driver 
may also refer to the actual executable program that is loaded onto the operating system or a portion thereof that 
imparts certain functionality. Drivers are in many instances, though not necessarily, associated with some form of hard- 
ware. 

As used herein, the term "lilter" refers to a portion of the functionality found within a software driver, including the 
entire driver itself, where connection points may be exposed for sending data through the filter. For example, a software 



driver may support a number of different filters or may have one single function. Furthermore, a number of filters from 
different drivers that are internally connected together and externally exposing connection points for input and output 
may collectively be referred to as a single filter. Also, in a more generic sense, the term filter may refer to the operation 
performed, such as decompression, etc, regardless of whether that occurs in a software driver filter running in kernel 
mode or another piece of program code running in user mode. 

As used herein, the term "driver object" refers to an operating system entity, defined by the operating system, for 
managing and making known a software driver as a system resource. 

As used herein, the term "device object" refers to a system level entity defined by the system, for making known a 
portion of a drivers functionality available for use as a system resource and defines the driver functionality and availa- 
bility to other system components. Both the driver objects and device objects are typically created upon loading and ini- 
tialization of the driver software. 

As used herein, the term "file object" refers to an operating system entity, defined by the system, for managing an 
invocation of a resource specified by a device object. A file object provides a context for usage of a driver object. Fur- 
thermore, a file object may be hierarchically related to another file object if the previous file object is designated as a 
"parent" during the creation of the new file object. File objects are typically used in managing all I/O operations that 
operate on a stream of data. 

As used herein, the term "data" refers to any information that is processed through the interconnected kernel mode 
filters. Such data includes media data representing video, audio, text, MIDI, etc. but may also include control information 
or parameters for other applications. For example, a kernel mode filter graph may be used in process control operations 
where the control information passed between the different filters is used to develop control signals for actuating 
machinery While examples are given of media processing systems, other applications could in like manner benefit from 
the system of interconnected kernel mode filters explained herein. 

Throughout this specification, the description of the present invention is described within the context of the Win- 
dows NT™ operating system available from [\/licrosoft®. Furthermore, familiarity with the Windows NT I/O architecture 
is presumed in order to understand the preferred embodiment explained herein. A good tutorial of the I/O system as 
well as the NT operating system in general can be found in the book "Inside Windows NT' written by Helen Custer and 
published by Microsoft Press. 

While the discussion of the drivers and system entities such as file objects, device objects and driver objects are 
explained herein within the context of how they operate in the Windows NT operating system, those skilled in the art will 
appreciate that the present invention may be implemented on other operating systems having analogous components, 
whether or not they use the same terminology. For example, should another operating system have an entity that oper- 
ates as a file object, it could be interpreted as a file object regardless of its actual title: 

The present invention will now be described, by way of example only, with reference to the accompanying drawings, 
in which: \ 

Figure 1 is a prior art data flow diagram showing a system of interconnected filters and drivers under the direction 
of a controlling agent for bringing sound data from a disk file, processing the sound data in some form, and render- 
ing the sound data to be played through a speaker. 

Figure 2 shows a system according to the present invention having the same purpose as that shown in Figure 1 to 
read sound data from a disk drive, process that data, and render that data to be heard on a speaker, wherein the 
processing filters and rendering are handled by interconnected kernel mode drivers, again under the direction of a 
controlling agent. 

Figure 3 is a vertical relationship model showing the relationships between driver objects, device objects and file 
objects as created and used in an operating system. 

Figures 4A, 4B and 4C are logical block diagrams of a driver object, device object, and file object, respectively, 
showing their logical relationship with the data structures and program code to route messages to appropriate proc- 
ess handling code and to validate the creation of new file objects according to the system of the present invention. 
Figure 5 is a flowchart showing the initial set up of the routing and validation componentry and the processing of 
I/O messages by the kernel mode drivers. 

Figure 6 is a flowchart showing in more detail the processing of a controlling agent, the routing and validation mech- 
anisms, and specific create handler routines for creating a new file object. 

Figure 7 is a logical diagram showing the horizontal relationship between connected filters utilizing the file object 
structures in an operating system to effectuate such a connection in a standardized fashion. 
Figure 8 is a flowchart showing the processing steps taken by a controlling agent in user mode to create and con- 
nect the kernel mode filters or drivers of Figure 7 in order to effectuate a connection for processing I/O requests 
received from the controlling agent with processing continuing between different drivers (filters). 
Figures 9A and 98 are logical overview diagrams of the kernel mode drivers and connections used to create a 
chain of kernel mode filters under the direction of a user mode controlling agent to implement a system for reading 



sound data from a hard drive, processing tlie data with the kernel mode filters, and rendering the data to be heard 
through a speaker. 

Figure 10 is a flowchart showing the processing steps for creating the interconnected kernel mode drivers for the 
system shown in Figures 9A and 9B. 
5 Figures 1 1 A and 1 1 B illustrate the functioning of a buffer allocator mechanism. Figure 1 1 A shows a logical arrange- 
ment and processing of the allocated buffer frames as they are passed from one processing component to another. 
Figure 1 1 B illustrates a buffer allocator being represented as a file object that is a "child" of a file object representing 
an input pin instance in a system of interconnected kernel mode filters. Both Figures 1 1A and 1 1B illustrate the 
same filter graph topology. 

10 Figure 1 2 shows the buffer allocation in transitions of the system illustrated in Figures 9A and 9B utilizing buffer allo- 
cators for controlling the allocation of buffer frames. 

Figure 13 is a flow chart showing the processing steps for bringing data from a disk driver through a chain of inter- 
connected kernel mode filters and rendering the data on sound processing hardware specifically showing the oper- 
ation of buffer allocators and the actual data transferring between buffers for the system shown in Figure 12. 

15 

Referring to Figure 1 , an example system is presented for reading a stream of sound data from a disk drive and 
rendering that sound data so that it may be heard through a speaker according to the prior art model. An amount of data 
is stored on hard drive 20 representing sound in the form of digitized sound samples. Alternatively, the source of the 
sound data stream may be digitized information coming over a phone line, digitized information from network or other 

20 communication packets, or other sources known in the art. The data stream is composed of digitized samples having 
time interval information associated therewith either by data format and convention or by explicit timestamp information 
attached to each sample. A kernel mode disk driver 22 interacts with the disk drive hardware 20 and is under control of 
a user mode reader program component 24. A controlling agent 26 manages the different components in order to effec- 
tuate the rendering of the sound data and may include dynamic graph building capabilities so that the different software 

S5 components may be dynamically allocated in order to provide custom filtering or other processing paths as designated 
by an end user. 

The reader component 24 will interact with disk driver 22 using a standard I/O control interface of the operating sys- 
tem and will cause the compressed sound data to be read from the disk drive 20 into buffers allocated in user mode as 
part of the user mode process address space. Next, a decompressor component 28 will decompress the compressed 

30 data into its decompressed format for processing. As shown, this step is done entirely in user mode with the attendant 
lower priority and process behaviour safety mechanisms. 

The effects filter 30 will operate on the data to provide some special effect and will have an accompanying effects 
filter 32 operating in kernel mode. Furthermore, an effects processor 34 may be present or the effects filter may operate 
entirely in software emulating the actual hardware processor. In order to access the effects filter 32 the effects compo- 

35 nent 30 will use the system I/O control mechanism to transfer the data and control to the effects filter. Again, the kernel 
mode/user mode boundary is crossed in order to make this transition. 

The effects filter 32 will control the effects processor 34 and cause whatever special effect is necessary or desired 
to be made on the data. This may entail copying all the data from the effects component 30 down to the effects filter 32 
and again to the effects processor 34 depending on actual system configuration. While many software effects compo- 

40 nents have a hardware processor associated therewith, others function entirely within system software running on the 
host processor. 

After control and the data is transferred back into user mode at the completion of the processing of the effects com- 
ponent 30, it is then transferred to sound rendering component 36. The sound rendering component 36 will transfer the 
control and data to the sound rendering driver 38 which in turn controls the sound card 40 in order to render the data, 

45 as processed and filtered, as sound through speaker 42. As can be readily seen, there exists a variety of transfers 
between user mode and kernel mode that add inefficiencies to the rendering of the sound data. Because of the timing 
sensitive nature of multimedia data, such as a continuous stream of sound or video, it is advantageous to reduce these 
inefficiencies and transitions of control as well as the multiple copying of data between different buffers. 

One embodiment of the present invention and used throughout will consist of a service provided on the Windows 

50 NT operating system architecture. This service is broken into different software components that a user of the system 
will access. First, a user mode API is available that will include a routine for creating connection pin instances and other 
file objects representing particular functionality, such as a clock mechanism or a buffer allocation mechanism. Addition- 
ally, and more importantly, there will be a complete set of routines and data structures to assist the driver developer in 
making drivers that are compliant with the standardized architecture. By utilizing such facilities from the system, differ- 

55 ent driver developers may create compliant drivers that will interact with one another according to the specified archi- 
tecture. User mode agents communicate with compliant drivers through an environment subsystem running in user 
mode that will communicate with the system services of the NT executive and the I/O manager. This is the same stand- 
ard I/O mechanism for all other I/O and the present implementation of the preferred embodiment will utilize existing sys- 
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tem services as much as possible. . o a 

The architecture of the system of Figure 1 utilizing the present invention will appear as shown in Figure 2. A con- 
trolli^aaTnt 44 wi^i^^^^^^^^^^^ known in order to then make interconnections according to data format and con- 

5n Sit t^Sa^^ rendering entirely in kernel mode. Furthermore, the controlling agent will recede 
SatiSs irSprnmer ^ "hat it 'may exeLe control as necessary. Examples of such events would incite 

SSr^S^h^-S^^^ from disk dr^ 
rnnt oil ^k driver^t^^^^^ I Vertically" associated with disk driver 48 according to the NT layered I/O archit^u e as 
useS c?nvem^ a^^^^^^^^^^ T e term's vertically and horizontally are used to distinguish d-er connections that c^^^^^ 
rel occu^^^^^^^^^^ the NT layered 1/0 architecture (vertical) and connections according to the interconnected kernel 

"^^^r d^S^^S— -r S. ao^rding to the o^ec^on 

» ?Sre 2 iZing processing in kernel mode represents an efficiency advantage by el,m,.,at,ng ■""l«^^lmn- 
r«rSl^een useTLe and kernel mode and by reducing the amount of overttead normally associated »,tl, 

^I^lgure 3 a logical diagram sho»ing the hi«archal nature of system objects relat^J to Intercon- 
nect^sZre *^e^ c^Mant i one embodime,^ of the present invention is shown. A driver ob,ect 64 ,s crea.^ 
to TeSiertThe executable software code image as loaded In memory The driver cede image confabs the enti,«y of 
tSSs functiSty. and the driver object 64 includes information regarding the image, such as its location on the 

na^ch^teoflSrSrelSuefunctl^^^^^^ 
. "''Z2»t~a\%CVtof Object 66a, file objects are cheated represendng Independent instance 

*t™si%™r;ern«*^^^^^^ 
*r:.i=wraror«io^^^^^^^^^^^ 

the SI" oHhe file object represents, etc. The context information has system required 'nfojma^on and 

,5 urtheMn^^^^^^^^^^^ areas that can be given special meaning. An example of how the user definable area 

ca*be usX 1 be hown hereafter discussing the implementation of a validation and IRP routing method. 

?n ordSto provide connection pin instances, the file object 70 representing a filter instance w^l be used as a paren 

it^reorieS f i^^^^^ 70 and are hierarchally related to file object 70. The connection pin instances, as r^re- 
filte represented by t''e o jci ^ ^ i^to and then out of the filter instance (represented by 

°' ° Julttra S represented by a file object having a hierarchial relationship to another file object repre- 
sentee fLns^^^^^^^^^^^ information for the pin instance, other file objects may be hier^chi- 
c re^^^^^^^^^^ in order to represent other functionality so that proper context information is available. 



Context information is necessary to distinguish one pin instance from another according to the individual parameters 
used in creation, such as pin data format, communication type, etc. 

Other operational entities, such as a buffer allocation mechanism, a timing mechanism, etc, requiring either an indi- 
vidual context or user mode control through a handle may also be represented by f ile objeds. Furthermore, hierarchical 
relationships between the file objects (e.g.. a buffer allocation mechanism associated with f P^^^icular conn^^ 
instance) may be established if necessary by specifying a parent file object during creation of the child file object. These 
parent/child relationships exist to determine relationship and structure between the file objects representing the opera- 
Sonal entities Additionally, a particular type of "parent" file object will only be able to produce certain types of children 
file objects, thus requiring the creation validation mechanisms as explained hereafter. Again, such f ile obj^ s have cor- 
responding handles available in user mode that are returned to a client through a system API call such as NtCreateF.^. 

The handles to f ile objects are used by user mode clients, such as a controlling agent, to communicate with the ker- 
nel mode drivers. The hierarchical chain of file objects, device objects, and driver objects aHows the 1/0 subsystem to 
traverse back to the driver object through the hierarchically related file objects and device objects to arrive at the entry 
pdnts fnto the actual driver cixJe. Such entry points are references (e.g.. pointers) to functions in the software dnver 
S FuLrmore, each of the objects in the object pathway between a particular file object and the dnver object hav- 
ing the entry points to the software driver code provides important context information for the ^O subsystem .n creating 
IRPs as welUeferences into data structures used for properly routing IRPs according to the routing, and validation 

""h^T^^ other system objeds are process-spec«ic and are the means by which a user mode 

process will communicate with an underlying object. It is interesting to note that multiple handles may be created to ref- 
erence a single underlying system object, such as a file object. This means that multiple applications may be feeding 
information to a pin instance as represented by a file object. . _, . u- * 

One elemerS of information that is important for interconnecting different drivers is the device obj^ stack depth 
parameter. This will indicate the IRP stack location of a particular driver object. In this manner, a single IRP may be used 
and passed between interconnected drivers using the ^O manager, thereby providing a performance enhancernent 
0 er separately creating and sending IRPs between the various interconnected drivers. Alternatjyely, ^^^^^^^^^^ 
create through appropriate I/O manager calls new IRPs for each successive communication and cause each new IRP 
to be sent to the next driver in the chain of interconnected drivers. 

Referring now to Figures 4A-4C. extensions to the system driver objects, device objects, and file objects are shown 
that aS va?dation of file object creation of differing types as well as ^0 Request Packet (IRP) routing to appropnate 
handlers. Figure 4A shows a driver object 76 representing the executable code implementing one or more fiKe^ o 
other driver functionality. Within the driver object, the Windows NT architecture requires a reference to a create handler 
provided by the software driver developer. AccoKling to this embodiment, a multiple)dng dispatch function 78 is refer- 
enced from the driver object 76 as the create handler and will be used to route messages to particular create handlers 
repfn,5ln9 on the fife object type to be created. Operatfon of the multipfe)dng dispatch function 78 will be explained in 
connection with the flow chart shown in Figure 6 hereinafter. 

in like manner, other handlers from the driver object will indicate a multiplexing dispatch function and depending 
on imolementation they may be the same function. In other words, as explained in more detail below, each type ofl/0 
har^Te rrTfe^nre(^^^^ 

sion data in a de^^ce object and the context information in a file object in order to route the message to the appropriate 
hancJer The extension data in the device object that references a validation table will be used when no parent f He ob ect 
!?sp?cifi3on1creL operatfon. Othenvis^hepare^^ 

Rgure 4B shows a driver object 80 which has a particular device extension area 82 that can be utilized as desired 
by the driver developer and includes driver specific information. At a defined locatfon within the device ejension a ea 
82 of the driver obj^t 80 is a reference to a data structure, known as a file type validation table 84. corrta.n.ng string 
fep?esentSs of file object types 86 and references to the associated create handlers 88 for each f e type repre- 
sented Th^cr^^^ *""Ction will the utilize file type validation table 84 to validate the file object type 
0 belre^ted an^^^^^^^^^^^ controTover to the appropriate create handler as will be explained in detail hereafter m con^ 
nec^on with the discussion of Figure 6. The string to be validated is found in the IRP create request and originates from 
the file name string used with the NtCreateFile function call in user mode. The NtCreateF.le call is made within the user 
mode function cell to create a pin instance or other mechanism. . . ^ i 
Fi ure 4C shows a file object 90 having a file context area 92 that is free to be used by the software dnver deve^ 
oper. Reference is made from the file context area 92 to an IRP request handler table 94. The d/«erent type^^^^^^^^ 
; r^uest 96 are associated with references to particular handlers 98, and the appropriate •""'^P'^;;;^ f ^P^*^^^ 

wiS use this information to access the correct handler. In the case of determining the correct j^^"^'^^;^^^^^^^ 
structure known as a file type validation table 100 is referenced having string representatioris of < « ^^^^ ^P^^ 
and references 104 to the associated create handlers for each file type represented. For children file objects (/.e.. file 



objects that have another file object rather than a device object as parent), the type is represented by a string that is 
compared to the strings in the file object types 102. When a match is found, the associated create handler is accessed 
using a reference from the references 104 that is associated with the matched file object type string. If no match is 
found, then the request is invalid and an error indication made. 

Referring now to Figure 5, the installation procedure for setting up the creation validation and mechanism is shown. 
At step 1 06, the installing program will make reference in the driver object to the appropriate multiplexing dispatch func- 
tions. As shown in Figure 4A, the create handler points to a generic multiplexing dispatch function. In lil^e manner, all 
other handler references in the driver object 76 would point to other generic multiplexing dispatch functions germane to 
the particular handler as necessary Alternatively each handler reference could point to the same multiplexing dispatch 
function that could in turn process the IRP request and route it to the appropriate handler. Such an alternative multiplex- 
ing function will necessarily be more complex in order to accommodate different kinds of request (e.g., create, write, 
etc.) 

Next, at step 108, each device object created as part of the software driver executable code installation will be 
adjusted to reference the file type validation table 84 as shown in Figure 4B. Finally, at step 110, the processing of IRP 
requests will begin with the multiplexing dispatch function using the file type validation table 84 as referenced from the 
appropriate device object 80. 

When a file object is created, the appropriate IRP dispatch table 94 will be created and referenced along with the 
indexed file object type validation table 100 as necessary. The creation of the file object type validation tables occurs 
within the provided create handlers according to file object type. The data structures are created representing the IRP 
dispatch table 94 and the file object type validation table 100 and a reference thereto stored at a specific location with 
the file context information 92 of the particular file object 90 being created. 

Referring now to Figure 6, a flow chart is presented showing the operation of the create multiplexing dispatch func- 
tion and its validation mechanism including its interaction with the data structures referenced from the system driver 
objects, device objects, and file objects. At step 112, a user mode process sends an I/O request for creating a file 
object. This I/O create request is made using an invocation to the system API for NtCreateFile. At step 1 1 4, the I/O man- 
ager sends the IRP to the multiplexing dispatch function 78 based on the reference in the driver object 76 (see Figure 
4A). 

Once the multiplexing dispatch function 78 has the IRP for the create request, a test is made at step 1 16 to deter- 
mine if there is a parent file object. The information necessary to make this determination will be found within the IRP 
itself and originally be supplied by the user mode process. The user mode process will supply a handle referencing the 
"parent" file object as part of the create request and the NT system will create the IRP having the correct reference to 
the "parent" file object. 

If there is no parent file object, the right branch is taken, and the multiplexing dispatch function 78 uses the device 
extension 82 from the appropriate device object 80 to reference a file type validation table 84 (see Figure 4B) at step 
118. Using the validation table 84, the multiplexing dispatch function 78 will validate the file object type at step 120 by 
comparing the string in the request with the file object types 86 strings. 

If there is a matching string as determined at step 1 22, the appropriate create handler is accessed at step 1 24. Oth- 
erwise the create request is rejected at step 126. The create handler as accessed at step 124 will create, or cause to 
be created, the file object at step 1 26. With the created file object, the appropriate create handle will make the file object 
reference in the file context 92 to an IRP dispatch table 94 that it has previously created. 

Again at step 1 16, it may be determined that there is a parent file object present. If a parent file object is present, 
as determined at step 1 16 as found in the IRP associated with the create request, the multiplexing dispatch function 78 
uses the file context 92 from the parent file object 90 to reference an IRP dispatch table 94 (see Figure 40) at step 1 30. 
For a create request, the multiplexing dispatch function 78 will access a file type validation table 100, at step 132. Using 
the file type validation table 100, the multiplexing dispatch function 78 will validate the file object type at step 133 by 
comparing the string in the request with the file object types 102 strings, as was done above. 

If there is a matching string as determined at step 1 34, the appropriate create handler is accessed at step 1 38. 0th- 
enwise the create request is rejected at step 136. With the appropriate create handler, the file object is created at 140, 
and the create handler will make a new IRP dispatch table 94 for the newly created file object and will make reference 
in the newly created file object 90 file context area 92 to the newly created IRP dispatch table 94 at step 142. Note that 
the same file object structure as shown in Figure 4C is used to explain interaction with both the parent file object and 
the validly created child file object. While the same structure exists in both cases (once the new file object is created), 
they will be used differently and contain different information. 

Whenever a connection pin instance is created, a connection pin ID is passed that identifies the pin factory in the 
filter that "supports" the creation of the pin instance. Those skilled in the art will note that the connection pin ID may also 
be validated as a string in a validation table in much the same manner as the file object is validated and that other imple- 
mentation variations exist. ' 

In order to make connections between different drivers, a common mechanism must be present to assure that a 



given driver supports sucii interconnections. Tiiis common meciianism must allow discovery of filter capabilities includ- 
ing connection pin factory capabilities. Furthermore, such a mechanism should also be extensible to provide additional 
flexibility to driver developers. 

One mechanism chosen in the present embodiment for defining compliant drivers and allowing discovery of capa- 

5 bilities are identified "sets" of related items. This is a convenient mechanism to be used with existing I/O communication 
mechanisms. A set is logically defined as having a QUID (globally unique identifier) to identify the set as a whole and a 
RUID (relatively unique identifier, e.g.. relative within the set itself) for each element of functionality within the set. The 
set identifier and any other data structures necessary for operating with the chosen RUID item are passed as part of an 
I/O control call using the filter handle as a parameter. Only a small number of lOCTLs need to be allocated in order to 

10 implement a full system of functionality. As implemented, three different types of sets are established depending on 
their functions, requiring a total of four lOCTLs. Other implementations may use sets in a different manner. The partic- 
ular lOCTL will signal the handler for I/O control to interpret or use the chosen element (using the RUID) in a certain 
manner. Furthermore, control flags may be passed with the QUID and RUID to further specify control information. 
The first set type is a property set and is used in connection with values or settings found within the driver or on any 

15 associated hardware. Examples of such settings would be transfer rate, volume level, etc. One lOCTL is associated 
with property sets with a control flag differentiating between a "get" property and a "set" property command. In this man- 
ner the same data structure can be used to either set or get a particular property with the driver determining the action 
required based on the lOCTL used. The correct property is identified by the set identifier consisting of its unique QUID 
and RUID combination. 

20 Method sets are another type of set used and are a set of actions that can be performed by a driver. Only one 
lOGTL is needed to identify the method set with the correct method to be actuated identified by the unique GUID and 
RUID combination for the set identifier. Methods are used to control the driver and include such functions as initializing 
the driver for use, clearing buffers, etc. 

Event sets are used for managing events associated with driver processing, such as device change notification, 
25 data starvation notification, etc, or any other notification defined by the set that may be useful to a user mode applica- 
tion. Two lOCTLs are used, one for enabling a specified event and one for disabling a specified event, while any data 
structures necessary for a given event identified by a RUID can be shared whether enabling or disabling the event. 

To use a set. an I/O control operation is initiated using the specified lOCTL and reference to a data structure having 
the set GUID, RUID, and other necessary data {e.g., control flags, data structures, etc). For example, setting a volume 
30 property on a sound card driver would entail an I/O control operation using a property set lOCTL, a control flag indicat- 
ing a set property operation, the appropriate GUID for the property set having the volume setting, the specific RUID 
within that set indicates the volume property, and the new volume setting value. 

To query the sets supported, by type, an lOCTL for a particular set type (e.g.. property lOCTL, method lOCTL. or 
event enable lOCTL) having a null GUID and control flags to indicate supported set enumeration are issued as part of 
35 an I/O command and a list of set GUIDs supported will be returned. To query supported properties, methods, or events 
within a given set, the set GUID. set type lOCTL. a null RUID, and control flags indicating enumeration of supported ele- 
ments are used with the I/O operation. A list of supported RUIDs will be returned as a result of the I/O operation. This 
will allow a third party agent to determine which, if any. optional elements of an implemented set are supported. 

The written specification of a set uniquely identified by a GUID allows a documented mechanism that both driver 
40 developers and third party controlling agents may use as an implementation guide. The third party developer will know 
of a given driver's capabilities based on response to queries and preprogrammed knowledge based on the abstract set 
definition. Likewise, a driver developer may use the abstract set definition as a guide to implementing a set or group of 
sets providing known functionality to any third party agent. 

In order to provide the connection abilities described herein, a compliant driver must support certain sets. The fol- 
45 lowing tables illustrate some important kinds of information that may be supported in property set format and that can 
be used in implementing the present invention. The first table refers to properties about a connection pin factory that 
would be implemented by a filter, while the second table refers to properties about an actual connection pin instance 
that would be created by using a particular connection pin factory as a template. 
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TABLE 1 



Filter Properties and Their Use 


Property 


Description 


Connection Pin Factories 


Lists the different types of connection pin instances that may be created on a particular 
filter, each distinguishable type referred to as a pin factory Note that this is not the total 
number of connection pin instances which could be instantiated on this device, but the 
number of unique connection pin types, such as an audio input and audio output. 


Connection Instances 


Lists the number of instances already created of a given connection pin factory as well 
as the highest number of instances supported for that particular connection pin factory 
If the total cannot be determined until the filter is actually connected, this property will 
return a -1. 


Data Flow 


Lists the possible data flow direction of a connection pin factory with respect to a filter 
{e.g., into the filter, out of the filter, or either into or out of the filter). 


Communication 


Lists the communication requirements for a given connection pin factory in terms of 
processing IRPs. Some connection pin factories may not be interconnected but have 
other forms of control mechanisms associated therewith such as a "bridge" to a file 
source for data that represents a source point on a graph. The bridge control mecha- 
nism would allow setting of a filename indirectly where information is stored. 

In an exemplary implementation, an agent (which decides which pin factory to use for 
making a connection pin instance) must be able to understand the intrinsic meaning of 
a "none", "sink" or input, "source" or output, "both," and "bridge" communication types 
for a connection pin factory For example, a source connection pin instance requires a 
handle or reference to a sink connection pin instance, etc. 

In the communication type context, sink and source refer to the disposition of the con- 
nection pin instance in processing IRPs. A sink would receive the IRPs for processing, 
while a source would pass the IRPs onto the next appropriate processing component. 

There are two communication types that are neither sink nor source and represent end 
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enters or exits from the connected filters. A none designation indicates that the con- 
nection type may not be instantiated while a bridge communications type refers to an 
end point that may be instantiated so that specific properties may be manipulated. For 
example, a bridge end point that is part of a file reader will likely have a property that 
will contain the path and file name of a file that stores the data to be processed. 


Data Ranges 


Lists the possible data ranges that a connection pin factory may support, including the 
format of the data, if relevant. In one implementation, a count followed by an array of 
data ranges, which the connection pin type may support, is used as part of the prop- 
erty In that implementation, if different data ranges are supported under different 
mediums or interfaces (see below), different connection pin factories are available on 
a particular filter to accommodate such differences. Furthermore, each data range 
structure may be extended for format specific detail such as number of bits and chan- 
nels. 

The actual data format a connection pin instance uses is set during creation of the 
instance. The data range property is used to assist in determining what that actual 
data format should be for a particular connection pin instance and is accessed or que- 
ried by a third party controlling agent. 



TABLE 1 (continued) 



Filter Properties and Their Use 


Property 


Description 


Interfaces 


Lists other set GUIDs indicating the supported interfaces on a particular connection 
pin factory. An interface is the type or types of data that may be communicated through 
a connection pin factory For example, MIDI data, CD music, MPEG video, etc, would 
be interfaces in the sense that data has a particular convention and format that a filter 
could handle. 

Such interfaces also comprise protocols for submitting the data. An interface is inde- 
pendent of the medium by which it is communicated. 


Mediums 


Lists the supported mediums on a particular connection pin factory A medium is the 
way or mechanism by which information is transferred, such as IRP-based. sockets, 
etc. An interface may be defined on top of a variety of different mediums. In the pre- 
ferred embodiment and implementation explained herein, an IRP-based medium and 
file 10- based medium is used. 


Data Intersection 


Returns the first acceptable or "best" data format produced by a connection pin factory 
given a list of data ranges. This approach is used to allow a third party agent to deter- 
mine data requirements when chaining different filters together. In one implementation, 
the data intersection property is used to determine the best data format produced by a 
connection pin factory given the constraint of a list of data ranges. The list of data 
ranges may be acquired using the data ranges property on another pin factory that will 
be connected as explained previously 

A third party controlling agent, which has no knowledge of the data type specifics, may 
use the data range list of one connection pin factory and return the "best" {e.g., first 
acceptable data format) data format on the current connection pin factory Although a 
set of ranges of the two intersecting connection pin factories could be returned, only 
the best format is returned by the driver. In this manner, the third party controlling 
agent can apply this "best" data format to the next driver in the graph in order to create 
a virtual set of connections before actually initiating the creation of connection pin 
instances and connecting the entire graph of filters together. This allows the controlling 
agent to assess the viability of a particular filter graph selected by a user and point out 
potential problems to the user before actually connecting the graph. The data format 
returned can also be restricted by the formats available given the connections already 
made on the filter. 

This property is capable of returning an error if a particular data format cannot be 
determined until an actual connection is made or if an intersection is dependent on 
multiple data formats on different connection points. Essentially intersection informa- 
tion is provided while the property itself will return a data format. 



TABLE 2 



Connection Pin Instance Properties and Their Use 


Property 


Description 


State 


Describes the current state of the connection pin instance. Possible states include being stopped, 
acquiring data, processing data, being paused or idle, etc. The state represents the current mode of 
the connection pin instance, and determines the current capabilities and resource usage of the 
driver. 

The stop state is the initial state of the connection pin instance, and represents the mode of least 
resource usage. The stop state also represents a point wherein there will be the most latency in data 
processing in order to arrive at the run state. The acquire state represents the mode at which 
resources are acquired (such as buffer allocators) though no data may be transferred in this state. 
The pause state represents the mode of most resource usage and a correspondingly low processing 
latency to arrive at a run state. Data may be transferred or "prerolled" in this state, though this is not 
actually a run state. The run state represents a mode where data is actually consumed or produced 
{i.e., transferred and processed) at a connection pin instance. 

More resolution in control may be accomplished using custom properties depending on the purpose 
of the filter and the underlying hardware. For example, in order to make an external laser disk player 
spin up, one would set some sort of custom "mode" property specific to that class. Setting this prop- 
erty may also change the state of the device but not necessarily, depending on the effect of the mode. 


Priority 


Describes the priority of the connection pin instance for receiving access to resources managed by 
the filter and is used by the filter in resource allocation arbitration. This property, if supported, allows 
a third party controlling agent to indicate the priority placement of the particular pin instance relative 
to all other connection pin instances of all other drivers which may share limited resources with this 
particular connection and instance. 

This priority property may also be implemented to allow an agent to set finer tuning of the priority 
within a single class of priority. For example, a priority may have certain subclasses associated there- 
with. If two drivers competing for the same resources have the same priority class, then the subclass 
priority is used to determine resource allocation between the two drivers. If the subclass priority is 
also the same, then arbitrarily, the first connection pin instance will receive the resources. 


Data Format 


Used to get or set the data format for the connection pin instance. 



The previous tables are given by way of example and those skilled in the art will appreciate that many different prop- 
erties and schemes may be implemented in order to create the connections between different drivers. One important 
element is the standardization factor so that different driver manufacturers or development groups may create drivers 
that may be interconnected since they are able to implement the same property sets. 

Another useful property set gives topology information for the internal relationships of input and output connection 
pin factories on a given filter. This information will state the relationship of input pin factories and corresponding output 
pin factories on a given filter as well as what type of processing happens between the input and output pin factories. 
Examples of the processing that occurs would be different data transformations, data decompression, echo cancella- 
tion, etc. Such information is useful to an automated filter graph builder that will trace a hypothetical connection path 
using multiple filters before making actual connection pin instances and connections. Essentially, the topology informa- 
tion explains the internal structure of the filter and exposes this through a property set mechanism to inquiries from third 
party agents. 

Therefore, a compliant driver is simply one that implements the designated property set. This allows a third party 
controlling agent to make queries and settings to the compliant filter once it is determined that a given property set is 
supported. The overall goal is to acquire enough information on how to connect the differing filters together in order to 
form a filter graph. 

By using the generic set mechanism, a minimum of functionality may be implemented to support a compliant driver 
but still allow unlimited extensibility. A set may be defined in a written specification that can be independently coded by 
a multitude of different driver developers to create a system of interoperable and interconnectable drivers as long as 
particular sets are implemented. Furthermore, the specification can define mandatory properties, methods, and events 
that must be supported as well as optional properties, methods, and events that can be implemented depending on the 



driver functions and advanced capabilities. Besides the basic minimum commonality required, driver developers may 
incorporate additional functionality by defining their own sets and assigning them a GUID. 

Referring now to Figures 7 and 8, an illustration of the process for connecting two kernel mode filters is illustrated. 
Figure 7 shows a logical block description wherein each filter instance and connection pin instance is represented by 
file objects. Figure 8 is a flow chart illustrating the steps to creating the file objects and the appropriate connections. 

Beginning at step 1 44, an instance of Filter A 1 46 and an instance of Filter B 1 48 are created by a user mode agent. 
These are created using standard file system API for creating files with a particular device. Filter A 1 46 and Filter B 1 48 
will be compliant filters or drivers because of their implementing the appropriate property method, and event sets to 
support the creation of connection pin instances and for querying the respective filter's capabilities in terms of sets sup- 
ported and connection pin factories defined for that filter. 

The third party controlling agent will then query Filter A 146 and Filter B 148, respectively, at step 150 to determine 
connection pin factories available and the attributes for connection pin instances that may be created therefrom. These 
attributes include, as mentioned previously, the connection format and the data format for each individual type of pin 
instance for each respective filter 146 and 148. The querying will be accomplished using the set based query mecha- 
nisms explained in detail previously 

After querying such information, the third party controlling agent will determine the optimal connection format 
based on the ranges of data formats and connection formats previously queried. This determination occurs at step 152 
and places in the third party agent the ability to use the same filters in different ways according to the needs of a 
selected connection path. The third party controlling agent will use the data intersection property topology information, 
and connection pin factories on both the filters in order to determine how best to select data format and connection 
arrangements depending on the actual filter graph being made. 

Input filter pin instance 154 is created by the third party agent at step 156 using the optimal detection formation 
determined at step 152. Since input pin instance 154 is a file object, a handle will be returned from the create process 
that can be used for delivering I/O requests to the input instance 1 54. Furthermore, the creation of the input pin instance 
154 was validated and uses the routing and validity mechanisms shown previously in discussion with Figures 4A-4C, 5, 
and 6. 

In order to finalize the connection, output pin instance 1 58 is created at step 1 60 using as a parameter in the NtCre- 
ateFile call the handle of the previously created input pin instance 154. The effect of thus creating the output pin 
instance 158 is to utilize the system file management and I/O management facilities to create an internal IRP stack 
structure that allows an original write command to be consecutively processed by the variously connected connection 
pin instances and filters in an appropriate order so as to facilitate direct data flow between the differing filters. This 
requires that the input pin instance be created prior to the associated output pin instance that will be feeding the input 
pin instance. 

The stack depth parameter of a device object controls how many stack locations are created for an IRP sent to this 
driver. A stack depth parameter is assumed to be one when a device object is initially created and may be modified 
thereafter depending on the whether multiple drivers are chained together. In the current system, modification occurs, 
if necessary, when an output pin instance ti-ansitions from the initial "stop" state to the "acquire" or other state. Connec- 
tion pin instance state transition is the mechanism that determines correct stack depth parameter information for proper 
IRP creation and treatment. 

In order to allocate the internal IRP stack structure correctly for a chained set of connection pin instances, it is nec- 
essary to transition the connection pin instances out of the stop state in a specified order; beginning with the last input 
pin instance (in this case input pin instance 154) and working consecutively backwards to an associated {e.g., con- 
nected) output pin instance (in this case output pin instance 158). If many filters are chained together, the deepest fil- 
ter's or bridge's input pin instance must be the beginning point of transitioning and building successively backwards until 
the initial output pin instance on a bridge or filter is set. In other words, the transition out of the stop state must occur 
backwards up the chain so that each connection pin instance gets the stack size needed after the previous connection 
pin instance. Typically though not necessarily, a connection pin instance transitions from the stop state to the acquire 
state and for discussion purposes hereinafter transitioning to the acquire state will accomplish the same purpose with 
respect to stack depth parameter adjustment as transitioning out of the stop state. 

Once all pin instances are in the acquire state, stream reads and writes may be issued to the filter graph. It is inter- 
esting to note that the system explained herein allows connection of associated input and output pin instances to occur 
in any order; only the transition from the stop state must occur in bottom up or deepest first fashion. Furthermore, the 
filter graph is reconfigurable to allow changes to be made after initial creation. When changes are made, state transi- 
tions need only occur on those connection pin instances that are in the stop state in order to assure correct stack depth 
parameter information. 

Connection pin factories found on filters represent places where a filter can consume and/or produce data in a par- 
ticular format. For example, a particular connection pin factory may support a number of different data formats, such as 
1 6 bit 44 kilohertz PCM audio or 8 bit 22 kilohertz PCM audio. As explained previously the connection pin factories and 



their different capabilities such as data format can be queried from the filter using the appropriate property set mecha- 
nism and the system I/O facilities. Actual connection pin instances are created based on the information received from 
the pin factories. 

In a streaming environment, where a single stream write or stream read operation from a user mode agent will 
cause successive processing of the data through the connected filters, two main methods for IRP control can be used 
as part of the native facilities of the NT operating system. First, a separate IRP may be created by each filter and sent 
to the next filter for processing which will in turn create a new IRP for further processing down the chain. The other 
method is to use a single IRP and pass it between the successive filters using standard procedures provided for inter- 
acting with the I/O manager. If the first method of creating new IRPsfor each successive filter in the chain is used, inter- 
connection order between the filters is unimportant since the filter need only know the destination of the IRP in order to 
call the I/O manager and send the IRP to the designated filter. If an IRP is reused, it is important that the connection pin 
instance transitions from the stop state be made beginning from the last filter to receive the reused IRP for processing 
backwards up to the first filter to receive the reused IRP or to the filter that created the IRP for processing. 

The current embodiment and implementation of the interconnected kernel mode filters utilizes IRP sharing advan- 
tageously to ease complexity in driver development, allow more robust drivers to be created, and provide more efficient 
processing. The "bottom up" pin instance state transition path will ensure that the proper stack order is created in the 
IRP processed by the successive drivers and that each driver object has the appropriate stack depth parameter set. 
Furthermore, the current state of the receiving input pin instance is checked in order to assure that the state transition 
sequence has been properly followed. For this reason, the communications property of a particular connection pin fac- 
tory will determine the potential flow direction and aid in properly distributing the state transition of connection pin 
instances. 

When creating an output pin instance (or IRP source), a reference to a file object representing an input pin instance 
(or IRP sink) on another filter will be passed as part of the NtCreateFile call. The appropriate create handler will be exe- 
cuted as explained previously using the multiplexing dispatch function and device object/file object hierarchy This cre- 
ate handler will have access to the device object of the filter having the input pin instance (e.g.. Filter B 148 in Figure 
7) by way of the input connection pin instance file object (e.g., input pin instance 154). From the device object, the pre- 
vious stack depth parameter can be read, and the stack depth parameter of the device object for the filter having the 
output pin instance may be incremented. For example, the device object associated with Filter A 146 will have a stack 
depth parameter incremented from that of the device object associated with Filter B 148 for the connection illustrated 
in Figure 7. This normally occurs when transitioning out of the stop state and IRPs are not forwarded while a connection 
pin instance is in the stop state. 

When a filter processes an IRR it knows which stack frame or location within the IRP stack to access containing 
information designated for that particular filter by making reference to and using the stack depth parameter of the asso- 
ciated device object. Furthermore, the current filter will prepare the IRP for the next filter in the processing chain by dec- 
rementing the device object stack depth parameter to locate the next filters IRP stack location. 

The filter code is responsible for preparing the next location in the I RP stack and for calling the I/O manager to pass 
the IRP to the next filter as designated. In this manner, the filter may designate which file object representing a particular 
connection pin instance is to receive the IRP and the associated data for processing. Hence, the standard I/O manager 
calls such as loAttachDevice to stack the respective device objects for sequential processing of IRPs are not used. 

It is noteworthy that creating a connection between connection pin instances does not imply creating new device 
objects to represent the connection. A single underlying device object is used to support an instance of a filter and all 
connection pin instances on that filter. Specific information necessary for proper data processing is kept within the con- 
text area of the file object allowing the context information to be preserved while non-page memory use is kept at a min- 
imum. It is also noteworthy that while an IRP-based medium has been illustrated, other mediums for communication 
between the interconnected filters may be used, such as direct function calls on non-host hardware-to-hardware com- 
munication. 

Referring now to Figures 9A-9B and Figure 10, the proper creation, connection, and state transition order of the 
software drivers as shown in Figure 1 (prior art) and Figure 2 (higher level logical diagram of the interconnected kernel 
mode drivers) are presented. Figure 9A illustrates the logical structure encompassed by box 162 and the processing 
steps contained therein. Figure 9B shows the creation of the connection pin instances to complete the interconnection 
of kernel mode filters and comprises the processing steps encompassed by box 164 on the flow chart shown in Figure 

10. . . . ^ 

When in the state of Figure 9B, having all interconnections made, the kernel mode filter system is ready for reads 
and writes in order to effectuate processing. The I/O system will use the IRP stack information properly set by the cor- 
rect state transition process in order to pass the stream reads and writes onto the differing filter elements by way of their 
respective connection pin instances. It may be noted that some external software other than the agent used to create 
the graph, including a bridge or filter itself, as well as hardware will provide data for the stream reads and rights. 
After beginning at step 1 68, the controlling agent 1 70 will create instances of reader filter 1 72, decompressor filter 
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rsrrng"=Liror=rmTb:p=^ 
. '-irkp-^i^^rporn;".^^^^^^^^^ 

its functionality. A buffer allocator mechanism will ^J^^ P^^^^^^^^^^ a sound or video processing 

ensure certain placement of the data into ^P^f ^"^"^j'3,S°3",^^^^^^^ b^^Snment, frame size. etc. Further- 
card or where the previous buffer has ""^^^^P^.^^'^,f,f^^^^^^^ of buffer memory is indicated by a 
more, references to the buffer allocator mechanism to be ^^!^Xn!^^T^B^^^^^^^^^ component 21 4 has a 
.0 circle and all processing components will have such f ^^^f^ , J^^^^^^^^^^^^^ a^row 218. Furthermore, 

the sinkbuffer allocator 212 and accessed using ^^^^''^^ .^a^oTss^^ P^°^^^-9 

50 transform processing component 220 as representea "JJ"^ „ tor mechanism is indicated 

no buffer allocation or transferring of data from one bu«e ^o another s.^^^ "he transform processing component 220 
since buffer allocator reference 222 reference has a by arrow 230. 

performs an "in place" data transformation ,n the ^'^'X^ff'^^^^^^^^^ 224b, and frame 224c are 
Since the data has not been transferred to a Arrow 231 represents pass- 

:==breror;r=^^^^^^ 
.,::*nSsr==ratrg-^^^^^ 



ing as shown by arrow 234 between the frame 224b and 224c. Again, as depicted herein, frame 224a. frame 224b. and 
frame 224c are all the same frame allocated originally by source processing component 214 and are shown separately 
for illustration purposes. 

The sink processing component 21 0 will finish processing the data and free the allocated frame 224c within a buffer 
as presented by arrow 236. Since the sink component 210 is no longer using the buffer, the arrow 236 points inward to 
the sink processing component 21 0 and the frame may now be deallocated or reused. , . . 

Fiaure 11 B shows how a buffer allocator mechanism would be logically implemented in the scheme of intercon- 
nected kernel mode buffers that has been explained previously. Figures 11A and 11B both represent the same filter 
araoh topology and are used to better illustrate operation of the buffer allocator mechanism. The relevant drivere and 
portions thereof each have access points that allow user mode clients to control the driver and are represented by file 
objects. Intercommunication occurs using IRPs (whether created by kernel mode drivers or by the NT executive in 
response to user mode I/O operations). " . , . ^u ti, 

An instance of source processing component 238 {represented by a file object) has associated therewith an output 
Din instance 240 (also represented by a file object) that provides a source of connection to another filter instance. An 
input pin instance 242 that is a "child" of a transform filter 244 was created having a reference to the output pin instance 
240 in the manner explained previously in more detail. In like manner, a sinkfilter 246 having an input pin instance 248 
is connected to an output pin instance 250, that is related to the transform processing component 244. 

In the system of interconnected kernel mode software drivers, a buffer allocation mechanism is related to input pin 
instances and is said to be created or formed on the input pin instance. Furthermore, output pin instances will logically 
have reference to a buffer allocation mechanism, if necessary, and the filter having the output pin instance will util^e 
that reference to make any buffer frame allocations and data transfer to new frames prior to turning control to another 
processing component. As explained, a null reference will indicate that no data transfer to a new frame is necessary 
and that processing may occur in the existing frame, {I.e., after processing, the data is returned to the same buffer 
frame). Whether a buffer allocator reference is present is determined by the initial negotiation of the third party control- 
ling agent that created the filter graph. ..,h,l^ the 
The buffer allocator mechanism formed on an input pin instance 248 is represented by a file pt^ject whHe the 
dashed line 254 shows that the output pin instance 240 has reference (e.g., a pointer or handle) to the file object rep^ 
resenting the buffer allocator 252. In the example shown in Figure 1 1 B, frames of memory are allocated from system 

""'Tnce the filters may be interconnected in a number of different ways, a buffer allocator though available, may not 
be necessary A file object representing an instance of a buffer allocator will only be created should third-party con- 
trolling agent interconnecting the filters determine that it is necessary In this manner, filters "^^^ 'j; ^^connec^^^^ 
in a variety of configurations and still maintain optimal data transfer characteristics. Furthermore, default system buffer 
allocators can be provided to further reduce the development effort of driver developers. 

A third-party controlling agent will also query buffer requirements of connection pins as part of creating a hypothet- 
ical model before making actual filter connections. While some implementations may allow queries before pin instam^^ 
ation, the present embodiment requires that the actual connection pin instance be created before the buffe "g 
Requirements can be ascertained. Furthermore, the exemplary embodiment disclosed throughout is queried through 
use of the set mechanisms explained previously. , ,^oira = fiitor 

When a third party client or controlling agent completes the interconnections of kernel mode filters to n^ake a filter 
graph, it then initiates negotiation of allocator requirements using the handles of the input pin '"f "^^ J^^^^^^^^ 
instances). By convention, the input pin instances define buffer allocation requirements and provide a buffer aHocat on 
mechanism while the output pin instances have reference to any appropriate buffer allocation -"^^^hanisms assoa^^^^^ 
with the input pin instances. Those skilled in the art will understand that other conventions may be used to effectively 
accomplish the same results including reversing the buffer allocation responsibilities between the input and output pin 

'"%"uffer allocation requirements are ascertained by using a particular property set mechanism that will be supported 
bv all compliant filters. It may be noted that the "buffer allocator" property set may be organized in a number of different 
vLSionT a ma a^^^ other set. For example, the property set may have a single property wherein the Property is a 
datf rJctu e h^^^^^^^ information or the property set may have multiple properties, one for each distinrt 

framing rS^ ement element. A single property composed of a data structure is more effK^ient in some C'rciim^^^^^^^^ 
since fewVr property set queries are necessary by the third party controlling agent in order to retneve al the framing 
rSrU^nt information. Furthermore, a single data structure could be used not only to query requirement information 
but also for specifying parameters when an actual buffer allocator IS created. ,H=»o=trMr 
; The table below shows a non-exhaustive list of framing requirement elements that may be included in a data st uc- 
ture or as individual properties. Also included is an explanation of how such an element would be used in an exemplary 
embodiment. 



TABLE 3 

Buffer Allocator Framing Requirement Elements 



Element 



Description 



Control Options (Create) 



Requirements (Query) 



Allocation Pool Type 



Outstanding Frames 



Frame Size 



This element contains control options that are specified during buffer allocator creation 

I on a given connection pin instance. Some options include: 
System Memory: This control option indicates the use of system memory for buffer 
frame allocations. When specified, the buffer allocator must allocate memory from the 
pool (as specified in the allocation pool type element) located in system memory If this 
control option is not specified, it is assumed that the input connection pin instance (or 
sink pin) provides a system address mapping to on-board RAM or other form of storage 
on a device attached to the system. Such a device may be an add in card, a PCMCIA 

t card, etc. 

Downstream Compatibility: This control option specifies that the allocator framing ele- 
ments of the buffer allocator being created are compatible with the downstream alloca- 
tor. This option is normally specified when an in place modifier is assigned an allocator 
for copy butters. If the filter is not required to modify a given frame, it may submit the 
frame to the downstream filter without allocating an additional frame from the down- 
stream allocator . 

This element contains the allocator requirements for a connection pin instance (input or 
I sink) that are returned during the query of a connection point. Some potential require- 
ments include: 

In-place: This indicates that a connection pin instance has indicated that the filter may 
perform an in-place modification. Othenwise, a buffer must be allocated for receiving the 
I modified data. 

System Memory: The connection pin instance (input or sink) requires system memory 
1 for all buffer frame allocations. If this requirement is not set, it is then assumed that the 
I connection pin instance provides a system address mapping to on-board RAM or other 
I form of storage on a physical device. 
Frame Integrity: This requirement indicates that the connection pin instance requires 
that downstream filters maintain the data integrity of specified frames. This may be used 
when statistics are required of a previous frame in order to properly process the current 
1 frame. 

I Allocation Required: This requirement mandates that connection point must allocate 
I any frames sent. 

Preference Only Flag: This requirements flag indicates that the other requirements sig- 
I nailed are preferences only This means that the requirements indicate a preferred way 
of operation but the connection point will still operate correctly and process frames 

1 which do not meet the specified requirements^ 

1 This element determines the allocation pool type from which kernel mode entities will 

receive system memory for buffer frame allocation. 

I This element indicates the total number of allowable outstanding buffer frames that can 
be allocated. In this manner, the total size of the buffer can be controlled. Furthermore, 
specifying a zero for this element indicates that the filter (through a particular connec- 
tion pin instance) has no requirement f or limiting the number of outstanding frames. 
This element specifies the total size of a buffer frame. Again, specifying a zero for this 
I element indicates that the filter (through a particular connection pin instance) has no 
requirements for this member. 



TABLE 3 (continued) 



Buffer Allocator Framing Requirement Elements 


Element 


Description 


File Alignment 


This element specifies the alignment specification for allocating frames on certain 
boundaries. For example, an octal byte alignment may be specified. Furthermore, in the 
exemplary embodiment, the minimum alignment capability is on quad boundaries pro- 
viding optimal data access speed on current PC hardware architectures. 



Those skilled in the art will appreciate that there may be other relevant framing properties that may be included. 
Furthermore the buffer allocation mechanism as described herein functions in substantially the same manner regard- 
less of whether more buffer frame elements than specified in Table 3 are included or whether a subset of those specified 
are implemented. ■ 

When the filter graph requirements have been determined by the third party controlling agent, then the appropriate 
kernel mode buffer allocators may be created on the appropriate input connection pin instances. The client creates a 
buffer allocator instance using the handle of the appropriate connection pin instance and by specifying the appropriate 
creation parameters for the buffer allocator. In this manner, the resulting file object that represents a buffer allocator will 
be a child of the connection pin instance and will use the context information from that file object and the file object rep- 
resenting the instance of the filter itself for its proper creation. ■ ■ ■ . A 
In other words the same mechanism explained previously for validating creation of a connection pin instance and 
for routing messages to the appropriate handlers for a given connection pin instance will apply in like manner to the cre- 
ation of an instance of a buffer allocator. Again, the NtCreateFile call will be wrapped in a higher level function call as 

part of an API that third party controlling agent may use. , . ^ , ,■ 

Buffer allocator instances will be created, if at all. only on input pin instances in the presently explained embodi- 
ment If a buffer allocator instance handle is not specrfied to an output connection pin instance handle through an appro- 
priate API call, then the filter can assume that the stream segment submitted via stream I/O controls meet the filters 
requirements and it may freely modify the data in-place. , u .i,„.o 

A system supplied default allocator may be used by filter developers to simplify the task of providing buffer alloca- 
tion capabilities to input connection pin instances. The default allocator provides for a system memory buffer frame allo- 
. cation for those device drivers that are.able to transfer data from system memory but require specific memory allocation 
properties By using the default buffer allocator, a filter developer is relieved from the task of actually providing code to 
do the buffer allocation. The filter will still be written, however, to support the buffer allocation requirements request by 
supporting an appropriate property set. . 

To use the default allocator, the filter designer will (1) provide code to respond to the buffer allocation requirements 
requests and (2) place a default allocator creation handler reference in the validation table of the particular connection 
pin instance to which the default allocator pertains. In other words, when a create request for the allocator type mech- 
anism is submitted through the filter, a specific GUID string is matched in the validation table that in turn allows access 
to the default allocator creation handler. . 

The default buffer allocator uses system memory and will operate in accordance with the buffer allocator framing 
properties submitted as part of the creation request. Such a default allocator is likely to be used by various transform 
filters depending upon their particular function and, interconnection order. 

Filters requiring buffer allocators for on-board memory or other device dependent storage methods can provide a 
specific buffer allocator by supporting a buffer allocator property set and method set. For a filter specrfic^allocator, he 
filter will be responsible for providing program code to implement the entire functionality. The operation of the buffer allo- 
. cator, however, will be the same as for every buffer allocator, whether default or filter specrtic, so third party agents may 
interconnect the filters and buffer allocators properly. . ^. .u *«,^<„»=a 

The file object representing the buffer allocator, when successfully created, has contained in the file context area a 
Dointer to a data structure. This data structure will contain a dispatch table for directing IRPs to designated handlers 
based on the various IRP codes (e.g. create. 1/0 control, etc.) as well as other data areas and structures for maintaining 
the state of the buffer allocator. Some implementation dependent information that may be tracked includes reference to 
the file object of the connection pin instance to which the buffer allocator pertains, reference to an allocation framing 
requirements data structure, an event queue of those clients waiting for events, a queue of those allocation requests 
(received by an IRP. for example) that are outstanding, etc. ^ . ^- ■ ^ u«,«in 

There are two interfaces, or ways of communicating, available to the buffer allocation mechanism disclosed herein 
in the exemplary embodiment. First, all allocators must provide the IRP-based interface in order to communicate prop- 
erly with user mode clients. Optionally, if the allocation pool type can be serviced at the dispatch level (a raised priority 
level at which a limited subset of services are available, but at which lower priority tasks are blocked out on that proc- 



pssort of the ooerating system, a function table interface may be supported allowing interconnected filters to use direct 

a thread of execution and waiting for a context switch. ., , 

The IRP-based interface will successively process IRPs in the following fashion. When an allocate reques s sub. 

7 » th^. fnr iRP ha^Pd interface Those IRPs that could not be serviced previously will be in this request 
d;:;t,C°i»re Sng me direc, function cal, «e operates In the following iashion. When an a,,«a.e 
tLn to !-ow Ih^Uherets a free frame available. Upon receipt of this notrfication. the kernel mode requester will attempt 

40 transferred therein from disk 262. _ allocator reference of output pin instance 1 92 to 

aiS "L"^^ X^Xrelfor- .r*re Kave direct acc^s to controiiing tHe ^..er aiio- 
55 formation or other manipulation on the data as it brings it 1"*° ^^^^^^^^^^^ . 74 3t3p 278 This stream write 
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15 



20 



25 



hnff^rsllncator 264 Since a handle thereto was Stored With respect to output pin instance 2M 

modate the decompression eflect on the data. not be a 1:1 cor- 

,tisimpo.a«tono,e.t,=.when^^^^^^ 

denn°X:~'4^^^^^^^^^^^ 
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frames of system memory 260 are either reused or freed incorporated as computer 

Those sillied in the art will recognize that the P^^^^^ such as a magnetic disK CD- 
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buffer allocators thereby allocating and managing data buffers as necessary as determined by the third party com- 
ponent. 

5. A method as claimed in claim 1 , in which the interconnecting step comprises, for each pair of interconnected con- 
nection pin instances, the steps of: 

receiving, by a third party component, a first reference to a first connection pin instance related to a first driver, 
the first reference including a reference to a first buffer allocator for creating and managing data buffers if 
present on the first connection pin instance; 

receiving, by a third party component, a second reference to a second connection pin instance related to a sec- 
ond driver, the second reference including a reference to a second buffer allocator for creating and managing 
data buffers if present on the second connection pin instance; 

passing said first reference, by said third party component, to said second connection pin instance at said sec- 
ond driver; and 

passing said second reference, by said third party component, to said first connection pin instance at said first 
driver, said first and second connection pin instances to transfer data back and forth between connected 
respective first and second drivers only if there is a reference to a buffer allocator at the respective receiving 
driver otherwise the receiving driver to process the data at its existing location. 

6. A method as claimed in claim 1 . in which the interconnecting step comprises, for each pair of interconnected con- 
nection pin instances, the steps of: 

receiving, by a third party component, a reference to an input pin instance, said input pin instance to receive 
data for processing at a receiving driver, said reference including a reference to a buffer allocator, if present on 
said input pin instance; 

passing said reference, by said third party component, to an output pin instance, at a sending driver to thereby 
connect said drivers, said data being transferred to a data buffer under control of the receiving driver only if said 
reference to an input pin instance includes a reference to a buffer allocator othenwise said receiving driver to 
process the data in its existing location. 

7. A method for selectively transferring data from an existing buffer to a new buffer in order to facilitate data processing 
only when necessary while the data is sequentially processed by a first processing component followed by a sec- 
ond processing component, the method comprising the steps of: , 

forming a buffer allocator on the second processing component, if necessary to create and manage data buff- 
ers according to the requirements of the second processing component; and 

connecting the first processing component to the second processing component so that data will be processed 
by the first processing component followed by the second processing component, said connection incorporat- 
ing reference to the buffer allocator, if present, on the second processing component so that data is transferred 
from the existing buffer to the new buffer indicated by the buffer allocator only when the buffer allocator is 
present and if the buffer allocator is not present, the second processing component processing the data in its 
existing buffer. 

8. A method as claimed in claim 7, which includes the steps of: 

querying the second processing component, by a third party component, of its buffering requirements; and 
determining, by a third party component, whether a buffer allocator need be formed prior to formation of the 
buffer allocator. 

9. A method as claimed in claim 7, the second processing component is responsive to queries of its buffering require- 
ments. 

10. A method as claimed in claim 7, in which the buffer allocator formed on the second processing component allows 
management of buffers by implementing a uniquely identified set of methods. 

1 1 . A method as claimed in claim 7, in which the buffer allocator formed on the second processing component provides 
relevant notification of buffer status. 



1 2. A method as claimed in claim 7, in which the buffer allocator formed on the second processing component provides 
status and control of buffers. 

13. A method as claimed in claim 7, in which the buffer allocator formed on the second processing component provides 
status and control of buffers by implementing a uniquely identified set of properties. 

14. A method as claimed in claim 8, in which the first and second processing components are separate kernel mode 
software drivers. 

15. A method of interconnecting a first and second device driver to allow said device drivers to communicate with each 
other and transfer control for processing data using a kernel rnode connection in a standardized and extensible 
manner and further causing the data to be transferred from an existing buffer to a new buffer only if necessary, the 
method comprising: 

providing, by a third party component, a data format and a connection format to a first device driver; 
creating, by said first device driver and in response to said third party component, a first instance of said con- 
nection format and a handle to the instantiated connection including a reference to a buffer allocator formed on 
the first instance of said connection format, if formed thereon; 
returning, by said first device driver, said handle to said third party component; 

providing, by said third party component, said data format, said connection format, and said handle to said sec- 
ond device driver; and 

forming, by said second driver and in response to said third party component, a second instance of said con- 
nection format utilizing said handle, thereby allowing said first driver to transmit data from said existing buffer 
to a new buffer entirely within kernel mode through said first and second connection format instances only if 
said first connection format instance references a buffer allocator that indicates and manages the new buffer, 
the first driver othenwise passing data processing control only to said second driver to process the data in the 
existing buffer. 

16. A method as claimed in claim 15, which includes the steps of: 

querying, by a third party component, said first device driver to determine buffer requirements; 
■ supplying, to said third party component by said first driver in response to the query, the buffer requirements 
and options of the first device driver; and 

determining, by said third party component based on the supplied buffer requirements, whether to form a buffer 
allocator as part of the first connection format instance; and 

forming, if necessary, a buffer allocator on the connection format instance for creating and managing buffers. 

17. A kernel mode media rendering system comprising: 

a media source; 

a plurality of kernel mode media processing components including an originating component and a terminating 
component; 

the originating component reading media samples of a media stream from the media source; 
the terminating component rendering said media stream; 

each media processing component having connection pins for passing media samples between media 
processing components; and 

some pins having data buffers associated therewith; and 

kernel mode component interconnections between the media processing components created using the con- 
nection pins to route processing control of the media samples from the originating component to the terminat- 
ing component with the media samples transferred only between those pins having data buffers associated 
therewith. 
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